Databases are used to store information for an innumerable number of applications, including various commercial, industrial, technical, scientific and educational applications. Many databases are relational databases, which organize information into formally-defined tables consisting of rows (i.e., records) and columns (i.e., fields), and which are typically accessed using a standardized language such as Structured Query Language (SQL). Database management systems (DBMS's) are the computer programs that are used to access the information stored in a database via searches or queries against the database, and to modify the information stored in the database.
Databases are often enlisted to process transactions. Transactions include indivisible operations that must be fully completed or must be fully aborted. A typical transaction is a banking transaction for moving money from one account to another. This transaction typically includes at least two indivisible operations such as removing money from one account and adding money to the other account. The operations are indivisible because both of them must be successfully completed to maintain the accuracy of the two accounts.
If all the operations are successfully completed, then the computer system “commits” the transaction, for example, via an SQL COMMIT statement. By committing, all the changes are made permanent in the database containing the account information. However, if an error occurs (e.g., due to a computer crash) and an operation cannot be completed, the computer system rolls back all of the operations, including any successfully completed operations, via an SQL ROLLBACK statement, to undue all the changes. As such, the database containing the account information may be restored to its known, original state prior to the transaction.
Many modern computer systems are distributed systems, and as such, transactions are also distributed. A typically distributed system is a client-server. The client-server is a type of distributed network architecture, which enables a client to make a request to a server. The client is often a single user computer or a program running on the same, while the server is often a multi-user computer or a program running on the same. After receiving the request, the server (e.g., an application server) will process the request and typically generate a response back to the client. A server is typically located remotely from a client and can process requests from multiple clients.
One type of distributed transaction processing architecture capable of being used in client-server systems is referred to as the X/OpenXA standard. In XA transactions, multiple resource managers on multiple clients interact with their associated XAResources, which are also on the clients, and a transaction manager on a server typically handles the execution of transactions. The transaction manager typically handles the execution of multiple transactions as part of a global transaction. In particular, the transaction manager enlists the XAResources, communicates with the resource managers about the XAResources, and maintains a serialized transaction log of all the XAResources that are enlisted. An XA resource is typically any resource that can be utilized with XA such as a database, main frame, messaging service, etc.
Typically each XAResource that is enlisted by a transaction is explicitly configured, with information about the XAResource (e.g., XAResource and XAResourceInfo) stored once in the transaction log of the transaction manager at the beginning when the XAResource is first enlisted and then the information is referenced each time the transactions enlist that XAResource. Regardless of the resources enlisted, all the operations must still be committed or rolled back. To ensure that this occurs, a two-phase commit (2PC) protocol is often implemented. In the first phase, the transaction manager orders the resource managers to prepare to commit the enlisted XAResources. Depending on whether or not all the resource managers are successful, the transaction manger tells the resource managers to commit or roll back the operations on the XAResources in the second phase. To complete the processing, the resource managers associated with the XAResources are inflated to invoke (a) prepare and (b) commit or rollback (i.e., 2PC). If committed, the resource managers then contact the XAResources and the specified operations (e.g., an SQL verb) are performed on the XAResources. This is generally illustrated in FIG. 4 with two XAResources (i.e., XA1 resource at connection conn1 and XA2 resource at connection conn2).
In case the transaction needs to be recovered, the transaction log may be utilized to determine which XAResources were enlisted. After they are identified, the resource managers associated with those XAResources may be contacted to perform 2PC on those resources. Specifically, the transaction manager stores a serializable factory that can be used to return the XAResource instances. The transaction manager serializes the factory and when required, inflates it, obtains a XAResource instance, and then calls 2PC.
However, often times a XAResource serves as a proxy for other XAResources and generally represents other XAResources. For example, the XAResource may be a virtual resource such as a virtual database that is partitioned across hundreds of separate computers (e.g., over a grid of thousands of server computers). Databases are often partitioned across many computers to improve efficiency, to perform maintenance of a portion of the database, etc. However, conventional techniques assume that the XAResource that was enlisted in the transaction log is the XAResource that will be utilized during execution. As such, XAResources represented by the resource in the transaction log are generally not included in the transaction log. Moreover, it may not be until runtime, after execution of the transaction has begun and at commit time that the exact XAResources that are being enlisted will be known and cannot be preconfigured, instead, only the proxy might be preconfigured. As such, this may cause errors, bottlenecks, and may hinder recovery of the transaction because there may be no record of the actual XAResources enlisted. Furthermore, even if some of these resources were known, it may not be efficient to try to configure all of them.
As an example, suppose there are ten resource managers associated with ten virtual databases that represent other resources. There is also a transaction and a subset of those virtual resources will be selected for the transaction. As such, the selected subset of virtual resources may be preconfigured, enlisted, and entered in the transaction log of the transaction manager. The transaction log typically does not indicate any of the other resources represented by the virtual resources that were enlisted. Moreover, the transaction manager will generally incorrectly operate under the impression that the resources in the transaction log are the only ones being utilized to execute the transaction. Even the resource managers associated with the selected subset of virtual resources generally have no way to determine which resources represented by the virtual resources were actually enlisted during runtime.
A need therefore exists for an improved manner of processing transactions, in particular, an improved manner of keeping track of the resources that are dynamically enlisted to execute a transaction and not known before runtime.